Internet Info 1994 March/Internet Info CD-ROM (Walnut Creek) (March 1994).iso/inet/internet-drafts/draft-ietf-bgpdepl-nsfnet-support-00.txt

Text File | 1993-03-26 | 15KB | 460 lines

Network Working Group                                   Mark Knopper
INTERNET DRAFT                                          Merit/NSFNET
                                                        March 1993


       Aggregation Support in the NSFNET Policy Routing Database


Status of this memo


   This document is an Internet Draft. Internet Drafts are working
   documents of the Internet Engineering Task Force (IETF), its Areas,
   and its Working Groups. Note that other groups may also distribute
   working documents as Internet Drafts.

   Internet Drafts are draft documents valid for a maximum of six
   months. Internet Drafts may be updated, replaced, or obsoleted by
   other documents at any time. It is not appropriate to use Internet
   Drafts as reference material or to cite them other than as a "working
   draft" or "work in progress."

   Please check the 1id-abstracts.txt listing contained in the
   internet-drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net,
   nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the
   current status of any Internet Draft.


0. Abstract

   This memo describes plans for support of route aggregation, as
   specified in the descriptions of Classless Inter-Domain Routing [1]
   and the BGP-4 protocol [2], by the NSFNET Backbone Network Service.
   Mechanisms for exchange of route aggregates between the backbone
   service and regional and midlevel networks are specified.
   Additionally, the memo proposes the implementation of an Aggregate
   Registry which can be used by network service providers to share
   information about the use of aggregation.

1. Introduction


   The Internet network service provider community and router vendors
   have agreed that the time for deployment of route aggregation is very
   near. At the IETF meeting in November, 1992, this topic was discussed
   in the BGP-D, NJM and ORAD working groups; it was a discussion topic
   of the NSFNET Regional-Techs Meeting in January, 1993; and it was
   also the topic of the March, 1993 meeting of several network service
   providers and router vendors (see meeting summary for this recent
   meeting in [3]).

   All have generally agreed that Summer, 1993 is the time to enable
   BGP-4 and CIDR aggregation. Each of the parties are responsible for
   their own aspect of CIDR implementation and practice. This memo



Expiration Date September 1993                                  [Page 1]





RFC DRAFT                                                     March 1993


   describes Merit's plans for support of aggregation on the NSFNET, and
   a proposal for implementing a database of aggregate information for
   use by network providers.


2. Aggregation Support by the Backbone Service


   The NSFNET backbone service includes a Policy Routing Database system
   which currently holds the set of network numbers that are accepted by
   the backbone service with a list of Autonomous System numbers from
   which announcements of these network numbers are expected. For the
   CIDR implementation the database system will be modified to allow
   aggregation of routing information to be configured. When the NSFNET
   service announces routes to regional peers, de-aggregation will not
   be done. If a peer needs to receive full routing information the peer
   should run the BGP-4 (or later IDRP) protocol which supports CIDR.


2.1 Current Configuration Capabilities


   An example of the way a network number is currently configured is as
   follows:

      35              1:237   2:233   3:183   4:266   5:267

   Or, using the syntax proposed by the Yu, Chen and Rekhter in "Inter-
   Domain Routing Policy Description and Sharing" [4], this would be
   better specified as:

      ACCEPT dst 35 and AS_path 237 = 1
      ACCEPT dst 35 and AS_path 233 = 2
      ACCEPT dst 35 and AS_path 183 = 3
      ACCEPT dst 35 and AS_path 266 = 4
      ACCEPT dst 35 and AS_path 267 = 5

      This shows that network number 35 (ie. 35.0.0.0, a class A net
      number) is configured on the T3 backbone such that it can be
      reached via 5 autonomous systems. The primary path is via AS 237,
      secondary is via AS 233, etc.

2.2 New Configuration Features for Aggregation


   There will be three new capabilities for which the backbone service
   can be configured to support aggregation. The first two allow
   aggregates to be stored in the backbone routing tables based on
   announcements by the regional network (autonomous system or AS)
   peers. The third allows the announcement of aggregates to the AS
   neighbor peers. The following sections give examples of the three
   features:





Expiration Date September 1993                                  [Page 2]





RFC DRAFT                                                     March 1993


2.2.1 NSFNET accepts aggregates


   In this case the regional peer router is CIDR-capable (runs BGP-4)
   and the announcement comes into the backbone as an IP address prefix.

   An example of the first method is as follows. The syntax for ACCEPT
   can be modified to handle aggregates as well as single networks.

      ACCEPT dst <192.64.128 17> AS_path 189 = 1
      ACCEPT dst <192.64.128 17> AS_path 24  = 2
      ACCEPT dst <192.64.128 17> AS_path 267 = 3

   Or a more compact way of storing the info might be more similar to
   the current NSFNET database:

      <192.64.128 17>         1:189 2:24 3:267


   In this example, independent of the "class" of IP network number, an
   aggregate containing network addresses matching a pattern in which
   the first 17 bits match the prefix 192.64.128 will be accepted in
   announcements to the NSFNET service. Primary path to destinations
   covered by the prefix is expected via AS 189, secondary via AS 24,
   etc.

2.2.2 NSFNET announces aggregates


   Currently the NSFNET database has a list of AS's or network numbers
   for each neighbor AS that are announced by the backbone to that AS.
   These announcements are specified currently by "announcetoAS"
   statements submitted by midlevels to Merit, and then included in the
   ANSnet router configuration files. There are two forms of these
   statements.  The first form uses the "norestrict" clause and
   indicates that all of the network numbers within each AS in the list
   should be announced to the neighbor midlevel AS. For example:

      announcetoAS 42 norestrict ASlist 22 26 38 60 68

   In this example, the NSFNET is configured to announce to neighboring
   midlevel AS 42, all networks in the routing table that were announced
   from AS's 22, 26, 38, 60 and 68.

   If the "norestrict" keyword is changed to "restrict", this indicates
   that an explicit list of network numbers for the AS's in the list is
   specified in the configuration file. The NSFNET will only announce
   network numbers that were announced by the AS's in the list, *AND*
   that appear in the "restrict list" of network numbers submitted
   separately by the midlevel.

   This system will continue to work once aggregation is implemented.
   The norestrict (or equivalent keyword once the new software is
   deployed) function will specify that all network reachability



Expiration Date September 1993                                  [Page 3]





RFC DRAFT                                                     March 1993


   information received from a set of Autonomous Systems, including any
   aggregates, will be announced.

   Depending on implementation in the gated software, it may also be
   possible to provide more specific restrictions on which aggregates
   reachable within an AS will and which will not be announced to a
   neighbor AS. Again using syntax similar to what is described in the
   RPDL paper, the following examples can be used to describe outbound
   aggregation policy:

      ANNOUNCE dst <192.64.128  17> to 22

   The above specifies that the given aggregate is announced to neighbor
   AS 22.

      ANNOUNCE * AND (! dst <193 16>) to 42


   The above example uses a logical expression style and specifies that
   all ("*") networks or aggregates with the exception of 193.0.0.0 mask
   255.255.0.0 are announced to neighbor AS 42.

   More elaborate announcement policies can be imagined. This discussion
   provides examples of what might be available but it has not been
   resolved yet just what capabilities will be offered initially.


2.2.3 NSFNET aggregates by proxy


   The other method is where the backbone is configured to perform
   aggregation on behalf of a CIDR-incapable regional.  An example of
   this aggregation technique is:

      AGGR <192.64.192 AND 192.64.129> => <192.64.128 17>
      ACCEPT dst <192.64.128 17> and AS_path 189 = 1
      ACCEPT dst <192.64.128 17> and AS_path 267 = 2


   In this example, the same class-independent set of IP addresses will
   be stored and propagated within the backbone as an aggregate under a
   set of conditions. This example has the conditions such that when
   both networks 192.64.192 and 192.64.129 are made to the backbone
   (through either AS 189 or AS 24 or AS 267) it will aggregate the
   whole block. If only one of the networks is announced to the
   backbone, no aggregation will be performed. In this case additional
   ACCEPT clauses may be present which allow acceptance of the single
   network numbers.









Expiration Date September 1993                                  [Page 4]





RFC DRAFT                                                     March 1993


3.0  Aggregate Registry


   In discussions with network providers it has become apparent that
   there is a great need for sharing of aggregate information globally.
   In addition to implementing the capability of including aggregation
   information in the NSFNET Policy Routing Database (as described in
   section 2), there is a need to have a separate database that will
   allow aggregate information from any Autonomous System to be stored
   and made available for easy electronic retrieval. The information can
   be used for routing coordination and policy configuration in the
   larger inter-domain context.

   One of the expected uses of such a database is to help determine the
   granularity of aggregation of network reachability information with
   respect to policy. It may be desirable in some cases to aggregate
   broadly, for example all networks whose numbers conform to a binary
   prefix pattern within an entire nationwide network. This case may be
   rare since it may be unlikely that there is a backbone whose routing
   policy is the same for all of its constituent networks.  Some of this
   depends on how network number allocation has been handled, or whether
   the network provider has renumbered its client networks to conform to
   CIDR aggregation boundaries. Rules for network number allocation with
   CIDR are discussed in [5] and [6].

   Merit proposes to implement an "Aggregate Registry" to provide
   sharing of aggregate information for the Internet inter-domain
   routing community. Initially this will be a simple database without
   much structure. It is not intended to hold only aggregates which are
   announced or accepted by the NSFNET service, rather it should be a
   community registry that all will be invited to use and make use of.

   The Aggregate Registry will consist of a list of aggregate
   announcement statements. Each statement consists of three types of
   information, along with contact information:

      1) The aggregate identifier, consisting of a network number prefix
      and the prefix length. For example <192.29.128 16>.

      2) The source AS number for the aggregate. That is, the AS number
      of the network service provider that initially aggregates the
      network reachability information into the aggregate for
      announcement to its neighbors.

      3) A list of neighbor AS's to whom the aggregate will be announced
      by the source AS.

      4) Contact information, eg. e-mail address and name or NIC handle
      of the administrative and technical contacts for the source AS.


   Thus, a given aggregate is only listed once in the table by the
   source AS.




Expiration Date September 1993                                  [Page 5]





RFC DRAFT                                                     March 1993


   Note that this registry reflects both the simple list of aggregates
   that are supported by the union of network providers, as well as
   providing information on inter-domain topology for the Internet.
   Merit will implement procedures for aggregates handled by the NSFNET
   to be registered here as well as procedures for updating the
   information when routing announcements change. Requests to update the
   information will be handled by e-mail to a staff mailing list at
   Merit.


4.0  Conclusions and Next Steps


   Implementation of CIDR is underway, and there is still a fair amount
   of planning and discussion that is needed for a successful
   transition.  Merit is proposing specific functions for CIDR
   aggregation that will be supported by the NSFNET, as well as an
   Aggregate Registry that can serve as the basis for inter-domain
   routing coordination for CIDR.

   Once this paper is discussed, Merit and ANS will make a specific
   description of CIDR functionality in the NSFNET service and ANS
   backbone available. The policies and administrative procedures as
   well as the technical capabilities of the backbone need to be
   defined.

   The Aggregate Registry will allow a set of tools to be developed that
   can facilitate the design of aggregation policy. A query tool to
   allow lookup of aggregation information for a given network or
   aggregate would be very useful. It will also be possible to undertake
   to write an inter-domain topology mapping program based on the source
   and destination AS announcements stored in the Registry.









References


   [1] Fuller, V., Li, T., Yu, J., and Varadhan, K., `Supernetting: an
      Address Assignment and Aggregation Strategy', RFC1338, June 1992.
      Update, Work in Progress.

   [2] BGP-4 protocol

   [3] Topolcic CIDR meeting

   [4] J. Yu, E. Chen, Y. Rekhter, "Routing Policy Description and
   Sharing",



Expiration Date September 1993                                  [Page 6]





RFC DRAFT                                                     March 1993


       Work In Progress, March 1993.

   [5] Gerich, E., `Guidelines for Management of IP Address Space',
      RFC1366, October 1992. Update, Work in Progress.

   [6] Rekhter, Li RFC on Net Allocation Guidelines



















































Expiration Date September 1993                                  [Page 7]